home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / bbs / rfc / rfcxxxx_8.lha / rfc1672 < prev    next >
Text File  |  1995-07-26  |  6KB  |  172 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        N. Brownlee
  8. Request for Comments: 1672                    The University of Auckland
  9. Category: Informational                                      August 1994
  10.  
  11.  
  12.                     Accounting Requirements for IPng
  13.  
  14. Status of this Memo
  15.  
  16.    This memo provides information for the Internet community.  This memo
  17.    does not specify an Internet standard of any kind.  Distribution of
  18.    this memo is unlimited.
  19.  
  20. Abstract
  21.  
  22.    This document was submitted to the IETF IPng area in response to RFC
  23.    1550.  Publication of this document does not imply acceptance by the
  24.    IPng area of any ideas expressed within.  Comments should be
  25.    submitted to the big-internet@munnari.oz.au mailing list.
  26.  
  27. Summary
  28.  
  29.    This white paper discusses accounting requirements for IPng. It
  30.    recommends that all IPng packets carry accounting tags, which would
  31.    vary in size. In the simplest case a tag would simply be a voucher
  32.    identifying the party responsible for the packet. At other times tags
  33.    should also carry other higher-level accounting information.
  34.  
  35. Background
  36.  
  37.    The Internet Accounting Model - described in RFC 1272 - specifies how
  38.    accounting information is structured, and how it is collected for use
  39.    by accounting aplications.  The model is very general, with
  40.    accounting variables being defined for various layers of a protocol
  41.    stack.  The group's work has so far concentrated on the lower layers,
  42.    but the model can be extended simply by defining the variables
  43.    required, e.g., for session and application layers.
  44.  
  45.    Brian Carpenter [1] suggests that IPng packets should carry
  46.    authenticated (source, destination, transaction) triplets, which
  47.    could be used for policy-based routing and accounting. The following
  48.    sections explain how the transaction field - hereafter called an
  49.    'accounting tag' - could be used.
  50.  
  51. Lower-layer (Transport) Accounting
  52.  
  53.    At the lower (network) layers the tag would simply be a voucher. This
  54.    means it is an arbitrary string which identifies the party
  55.  
  56.  
  57.  
  58. Brownlee                                                        [Page 1]
  59.  
  60. RFC 1672            Accounting Requirements for IPng         August 1994
  61.  
  62.  
  63.    responsible, i.e., willing to pay for, a packet. It would initially
  64.    be set by the host which originates the packet, hence at that stage
  65.    the tag would identify the user who sent it.
  66.  
  67.    A tag could be changed at various points along a packet's path. This
  68.    could be done as part of the routing policy processing so as to
  69.    reflect changes of the party responsible over each section of the
  70.    path. For example:
  71.  
  72.         user - provider           tag identifies user
  73.         provider A - provider B   tag identifies provider A
  74.  
  75.    The tag could be used by accounting meters to identify the party
  76.    responsible for a traffic flow, without having to deduce this using
  77.    tables of rules. This should considerably simplify accounting for
  78.    transit traffic across intermediate networks.
  79.  
  80. Higher-layer (Session and Application) Accounting
  81.  
  82.    At higher layers there is a clear need to measure accounting
  83.    variables and communicate them to various points along a packet's
  84.    path, for example an application server may wish to inform a client
  85.    about its usage of resources. A tag containing this information could
  86.    be read by meters at any point along the packet's path for charging
  87.    purposes, and could also be used by the client to inform the user of
  88.    charges incurred.
  89.  
  90.    It would make the collection of accounting data much simpler if this
  91.    information was carried in a standard tag within each packet, rather
  92.    than having different protocols provide this service in differing
  93.    ways.
  94.  
  95.    For 'old' applications which remain unaware of the tag field, a meter
  96.    could be placed at a gateway for the application's host. This
  97.    'gateway' meter could determine what the application is by watching
  98.    its streams of packets, then set an appropriate value in thir tag
  99.    fields.
  100.  
  101. Structure of the accounting tag
  102.  
  103.    The two uses of tags outlined above must be able to coexist. Since
  104.    many - indeed most - of the packets will only carry a voucher, it
  105.    seems simplest to keep this as part of the routing tuple (see below).
  106.  
  107.    For the application variables, a separate tag seems sensible. This
  108.    would simply contain a list of the variables.  Having two tags in
  109.    this way would keep separate the management of routers and meters.
  110.  
  111.  
  112.  
  113.  
  114. Brownlee                                                        [Page 2]
  115.  
  116. RFC 1672            Accounting Requirements for IPng         August 1994
  117.  
  118.  
  119.    If the encryption/digital signature overhead of the second tag proves
  120.    to be too high, it should be possible to combine this with the
  121.    voucher.
  122.  
  123.    The fine detail of this, or at least the way variables are packed
  124.    into the tags, could be standardised by the Accounting Working Group
  125.    in due course. For the purpose of IPng all that is required is the
  126.    ability to carry one or two variable-size objects in every packet.
  127.  
  128. References
  129.  
  130.    [1] Carpenter, B., "IPng White Paper on Transition and Other
  131.        Considerations", RFC 1671, CERN, August 1994.
  132.  
  133. Security Considerations
  134.  
  135.        For IPng to provide reliable transport in a hostile environment,
  136.        routing and accounting information, i.e., the (source, dest,
  137.        network-tag) and (application-tag) tuples, must be tamper-proof.
  138.        Routers and meters which need to use the tuples will need to hold
  139.        appropriate keys for them. Network operators will have to plan
  140.        for this, for example by determining which routers need which
  141.        sets of keys. This will be neccessary in any case for reliable
  142.        policy-based routing, so the extra work required to set up
  143.        accounting meters should be acceptable.
  144.  
  145. Author's Address
  146.  
  147.        Nevil Brownlee
  148.        Deputy Director
  149.        Computer Centre, The University of Auckland
  150.        Private Bag 92019, Auckland, New Zealand
  151.  
  152.        Phone: +64 9 373 7599
  153.        Fax: +64 9 373 7425
  154.        EMail: n.brownlee@auckland.ac.nz
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Brownlee                                                        [Page 3]
  171.  
  172.